home *** CD-ROM | disk | FTP | other *** search
- SCCS Id: @(#)exesmurf.doc 3.1 91/01/29
- Copyright (c) Pierre Martineau and Stephen Spackman 1991, 1992, 1993.
- NetHack may be freely redistributed. See license for details.
- ============================
- PC NetHack Support Utilities
- ============================
- Last revision: 1991January29
-
- This file contains documentation for the NetHack MS-DOS support
- utility EXESMURF.EXE. This utility examines and modifies the load
- parameters of an .EXE file and can be used to split .OVL files off a
- monolithic overlaid executable using ovlmgr.
-
- EXESMURF
- --------
- exesmurf FILENAME[.EXT] /v
- exesmurf FILENAME[.EXT] /minN
- exesmurf FILENAME[.EXT] /maxN
- exesmurf FILENAME[.EXT] /l
- exesmurf FILENAME[.EXT] N... [/pPATTERN]
-
- The programme exesmurf is basically a reimplementation of Microsoft's
- EXEMOD utility. However, this incarnation is one that is
- "overlay-aware" (as they say). It will provide the user with
- information about the executable and its overlays, and allow you to
- modify the executable's parameters and overlay locations.
-
- This program is made available for all users who were not graced with a
- release of EXEMOD in their Microsoft product, or who need the
- additional functionality it provides.
-
- /v.
- If exesmurf is invoked with a filename as argument, optionally
- followed by a /v, the filename's exeheader is listed for your viewing
- pleasure, along with the headers of any Microsoft-format overlays the
- file may contain. The listing is verbose; if there are many overlays
- you will want to redirect the output. Note that the redundancy in the
- output listing largely reflects redundancy in the file structure.
-
- /minN, /maxN, /stackN.
- Exesmurf may also be used to modify the "minalloc", "maxalloc" and
- "stack" allocation parameters of the executable file. This can be
- accomplished with the /min, /max, and /stack flags respectively. Any
- arguments to these flags should be *immediately* followed by a decimal
- number N. Note that this is inconsistent with the arguments to EXEMOD
- which takes hex numbers, and *needs* a space between the flag and the
- number.
-
- /l.
- The /l option requests a version of the /v listing (see above) in
- which the information about overlays is very much compressed; only
- their decimal file and load sizes are given, in a multi-column format.
- The resulting display will generally fit on a single screen. This
- turns out to be very useful when contemplating appropriate parameters
- for the overlay splitting operation described next.
-
- N... [/pPATTERN].
- The overlay-unpacking function of exesmurf is invoked by following the
- filename argument by a sequence of decimal numbers. Each of these
- numbers is an overlay number at which a new external overlay file is
- to be started. The main executable file will keep its old name after
- the overlays have been unloaded; the original input file will be
- retained, with its extension changed to .BAK. By default, the output
- files will be derived from the input file name by appending a
- discriminating character (in sequence, 0, 1, ..., 9, a, b, ..., z) to
- the basename and changing the extension to .OVL; but if the basename
- is a full 8 characters long, the discriminating character will replace
- the last character instead. This default is chosen for compatibility
- with ovlmgr. The default may be overridden with the /p option, which
- specifies a file PATTERN - a file name, possibly complete with
- extension, containing one or more ? characters (* is not allowed),
- which will be replaced by discriminating characters. If there is
- exactly one questionmark, it will be replaced by a digit or letter in
- the sequence described above, but if more than one questionmark
- appears a decimal numbering scheme is used instead.
- Note that the numeric arguments are overlay numbers, not
- indices, and they indicate the starting overlays of files. This
- permits us to manipulate files in which (for some reason) the overlays
- are not stored in ascending order, but it does mean that if a
- mentioned overlay does not exist in the original file, no new overlay
- file will be started. This is a realistic risk, since the Microsoft
- linker does not seem to generate overlays at all if there is no actual
- code generated into the segments in question.
- Note further that this operation can be reversed with the DOS
- copy/b operation, always supposing that it works as documented in your
- release of the operating system: the overlays are simply moved
- page-by-page to the external files.
- No guarantees are made as to how this programme will behave if
- there is debug information or other strangeness stored after the last
- overlay in the file.
-
- Whenever exesmurf is invoked, the extension .EXE is assumed for the
- file if no extension is given. Other extensions are probably only
- meaningful for examining overlay files.
- ----------------------------------------------------------------------
- Stephen P Spackman stephen@estragon.uchicago.edu
- ----------------------------------------------------------------------
-